Redis(Remote Dictionary Server)

✒️ 2025-05-28 15:14 내용 수정

Redis(Remote Dictionary Server)

오픈소스 기반 비관계형 데이터베이스 관리시스템(DBMS)

공식 문서 : https://redis.io/
참고 자료 : wikipedia redis, Redis 레디스 알고 쓰자. - 정의, 저장방식, 아키텍처, 자료구조, 유효 기간, NHN FORWARD 2021 Redis 야무지게 사용하기
메모리에서 데이터를 관리하여 데이터 저장 및 조회 성능이 우수한 데이터베이스다.
- 주 메모리에 데이터를 저장하기에 디스크에 접속할 필요를 줄이고, CPU 명령을 적게 사용하는 알고리즘을 적용하여 데이터에 접근하기에 검색 시간 지연이 적다.
하지만 메모리에 데이터를 저장하기 때문에 용량이 큰 데이터를 저장하는 저장소로는 부적합하여 보조 데이터 저장소로 사용한다.
- 이를 보완하기 위한 저장 기법을 사용하여 주 저장소로 사용할 수도 있다.
키(key)를 값(value)에 매핑하는 자료 구조의 디렉터리이다.
사용자들이 실행한 명령어를 이벤트 루프(Event Loop) 방식으로 처리하기에 명령어들을 Event Queue에 적재하고 싱글 스레드로 하나씩 처리한다.

사용 용도

캐싱 : 인 메모리 데이터 저장소이기에 다른 DB 앞에 배치하여 액세스 지연 시간을 줄이고, 처리량을 늘려 다른 DB의 부담을 줄일 수 있다.
세션 관리 : Session 정보를 key와 TTL(Time To Live, 기간 후 스스로 삭제하는 값)로 저장하여 간단하게 세션 정보를 관리할 수 있다.
순위표 : Sorted Set 구조를 사용하여 동적 순위표를 생성할 수 있다.
속도 제한 : 이벤트 속도를 측정하고 필요할 경우 포럼의 게시물 수나 리소스 사용량 등을 제한하여 한도 초과 시의 조치를 취할 수 있다.
대기열 생성 : List 구조를 사용하여 영구 대기열을 생성할 수 있다.
채팅 및 메시징 : PUB/SUB 표준을 사용하여 채팅방및 실시간 코멘트 스트림 및 서버 상호 통신을 지원할 수 있다.

데이터 저장 방법

Redis는 인 메모리 데이터 스토어기 때문에 서버 재시작 시 모든 데이터가 유실된다.
복제 기능을 사용해도 사람의 실수가 발생하면 데이터 복원이 불가능하기에 Redis를 캐싱 이외의 목적으로 사용한다면 적절한 데이터 백업이 필요하다.

AOF(Append Only File) : 데이터를 변경하는 명령어가 들어오면 명령어를 모두 그대로 저장한다.
- 모든 데이터 변경 기록을 저장하기 때문에 데이터 유실이 적다.
- 파일에 로그가 계속 추가되기 때문에 RDB 방식보다 파일의 크기가 커지며, 로딩 속도도 느려진다.
- 주기적으로 압축해서 재 작성되는 과정이 필요하다.
RDB(snapshot) : 저장 당시에 메모리에 있는 데이터 그대로를 사진처럼 찍어 저장한다.
- 바이너리 파일 방식으로 저장된다.
- 시간 단위로로 여러 개의 스냅샷을 생성하고, 데이터 복원 시 스냅샷을 이용하여 데이터를 가져온다.
- 스냅샷 이후에 변경된 데이터는 복구하기 어려워 유실될 수 있다.

데이터 저장 방법 선택 기준

백업은 필요하나 어느 정도의 데이터 손실이 발생해도 괜찮다면 RDB를 단독으로 사용한다.
장애 발생 상황 직전까지의 모든 데이터가 보장되어야 한다면 AOF를 사용한다.
제일 강력한 내구성은 AOF와 RDB 모두 사용하는 것이다.

데이터 타입

String : 기본 데이터 유형이며, 텍스트 또는 이진 데이터가 포함된다.
- 최대 크기는 512 MB이다.
- 단순 증감 연산을 사용할 때 INCR/INCRBY/INCRBYFLOAT/HINCRBY/HINCRBYFLOAT/ZINCRBY를 사용하여 카운팅을 수행할 수 있다.

"Test data"

# score:a 라는 key에 10이란 값을 저장
SET score:a 10

# 1 만큼 증가
INCR score:a
# > 11

# 4 만큼 증가
INCRBY score:a 4
# > 15

Bitmap : 비트 단위의 연산이 가능한 타입이다.
- 비트를 사용한 카운팅 연산(BITCOUNT) 시 데이터 저장 공간을 절약할 수 있다.
- 하지만 모든 데이터를 정수로 표현할 수 있어야 사용할 수 있다.

101011100110110

# visitors:20241115 라는 날짜 key를 생성
# 유저 id에 해당하는 bit를 1 상승
# 1개의 bit = 유저 1명
SETBIT visitors:20241115 3 1
# > 0

# 유저 id에 해당하는 bit를 1 상승
SETBIT visitors:20241115 6 1
# > 0

# 전체 1 비트 개수 카운팅
BITCOUNT visitors:20241115
# > 2

Lists : 나열된 데이터들을 가지는 리스트 타입이다.
- Java의 경우 List 인터페이스 같은 타입이 있다.
- Queue 타입을 사용할 때 리스트 타입을 사용한다.
- 메시징 기능에 사용할 때 Blocking 기능을 이용하여 Event Queue로 사용할 수 있다.
- LPUSHX/RPUSHX를 사용하여 key가 있을 때만 데이터를 저장할 수 있다.

{A, B, C, E, A}

Hashes : 해시 자료 구조로, 하나의 key 안에 또 다른 필드(field)와 값(value)으로 데이터를 저장하는 구조다.
- 해시 데이터는 Redis의 key와 매핑 되어 있어 해시 value를 생성 및 조회하려면 Redis key와 field를 동시에 사용해야 한다.

{"name":"park", "email":"testpark@google.com"}

Set : 중복되지 않는 데이터의 집합 구조다.
- Java의 경우 Set 인터페이스이 있다.

{A, B, C, D, E}

Sorted Set : Set과 비슷하지만 정렬 기능이 제공되어 있는 구조다.
- Set과 마찬가지로 중복 데이터를 허용하지 않으며, 데이터는 스코어(Score)와 함께 저장된다.
- 원래 Set은 정렬 기능이 없으나 Sorted Set에선 Score 값을 사용하여 정렬을 수행한다.
- 데이터를 저장할 때부터 Score 순으로 정렬되며, Score가 동일한 데이터는 사전 순으로 정렬한다.

{"park":1, "kim":2, "choi":3, "lee":4}

HyperLogLogs : 많은 데이터를 다룰 때 사용하며, 중복되지 않은 데이터의 개수를 파악할 대 사용하는 Redis의 자료 구조다.
- 모든 String 데이터 값을 유니크하게 구별할 수 있으며, Set과 비슷하나 대량의 데이터를 카운팅할 때 적절하다.
- 저장되는 데이터의 개수와 상관 없이 모든 값이 12 KB 값으로 고정되어 저장된다.
- 한 번 저장된 값은 다시 확인할 수 없어 들어온 데이터를 보호하기 위한 목적으로도 사용할 수 있다.
- PFADD : 데이터 저장
- PFCOUNT : 저장된 데이터 값 조회
- PFMERGE : 데이터를 종합하여 카운트

00101011 11010110 0001010

# 날짜별 url 크롤링 저장
PFADD crawled:20241115 "http://www.google.com/"
# > 1

PFADD crawled:20241115 "http://www.naver.com/"
# > 1

PFADD crawled:20241115 "http://www.youtube.com/"
# > 1

# 데이터를 수 백만 건 저장 후

# 20241115에 크롤링한 데이터 수 카운트
PFCOUNT crawled:20241115
# > 103429

# 날짜별로 모든 데이터 취합 후 카운트
PFMERGE crawled:20241115 crawled:20241116 crawled:20241117 ...
# > 809324

Streams : Redis 5.0부터 제공하며, Stream key 이름과 field, value를 사용할 수 있는 자료 구조다.
- 이벤트 성 로그를 처리할 때, 메시징 기능을 사용할 때 사용할 수 있다.
- 실제 서버에 데이터가 쌓이는 것처럼 append-only 방식으로 저장되어 중간에 데이터가 바뀌지 않는다.
  - append-only : 새 데이터는 저장소에 추가할 수 있으나 기존 데이터는 수정 불가능한 컴퓨터의 데이터 저장 특성

{"id": 93810, {"f1":"v1", "f2":"v2"}}